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RULE BASED CAPACITY MANAGEMENT 
SYSTEM FOR AN INTER OFFICE FACILITY 

Cross References 

[0001] This application is a continuation of U.S. Patent Application Serial No. 
10/171,375, filed on June 13, 2002, which is a continuation of U.S. Patent Application 
Serial No. 09/687,635, filed on October 13, 2000, and issued on August 13, 2002, as 
U.S. Patent No. 6,434,514. 

Background 

[0002] The present invention relates generally to monitoring systems and more 
particularly, to a system and method for monitoring and analyzing one or more 
pieces of telecommunication network equipment via a rule based system. 
[0003] It is often desired to monitor specific pieces of equipment of a 
telecommunication network. Traditionally, the monitoring has been provided in a 
flat-file, data dump format. For example, a conventional monitoring system can 
show if a piece of equipment in a network is up or down. 

[0004] However, it is often desired to have a deeper analysis of the equipment. 
Consider for example an inter-office facility, or "IOF". An IOF can generically 
represent any node (or group of nodes) in a telecommunication network, and more 
specifically identifies one or more pieces of equipment used to interconnect various 
links or nodes, such as other networks, telephone lines, and/or trunks. 
[0005] One way to monitor equipment in an IOF is to use a system called the 
Trunks Integrated Record Keeping System ("TIRKS"). TIRKS is commonly used to 
help a regional bell operating company ("RBOC") determine if facilities exist to 
provide service, track order completion, fulfill circuit orders, and perform inventory 
planning. 

[0006] Although TIRKS provides a great detail of information, the method of 
acquiring the information is very long and tedious. For example, in order to review 
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equipment of an IOF, many steps must be performed on TIRKS. The information 
provided by TIRKS is in a raw-data format, and must be manually complied into a 
tabular form to represent the desired information (e.g., exhaust conditions of one or 
more pieces of equipment). If there is an exhaust condition, a new job must be 
created for TIRKS, and a job story must be manually created to satisfy various RBOC 
reporting requirements. 

[0007] What is desired is a system and method that automatically monitors one or 
more pieces of equipment, analyzes the pieces of equipment, and creates review 
and/or reports from the analysis. 

Brief Description of the Drawings 

[0008] Fig. 1 is a simplified description of several typical telecommunication 
networks and a monitor system according to one or more embodiments of the present 
invention. 

[0009] Fig. 2 illustrates one embodiment of the monitoring system of Fig. 1. 
[0010] Fig. 3 is a block diagram of an exemplary inter-office facility including 
several different pieces of equipment, which the present embodiment may monitor. 
Figs. 4-5 provide a simplified diagram and flow chart that illustrates one embodiment 
of a software program for implementing features of the present invention. 
Fig. 6 is a flow chart that illustrates one embodiment of an inference engine for the 
software program of Figs. 4-5. 

[0011] Figs. 7-10, 12-14 provide screen shots, such as from the computer system of 
Fig. 2, that illustrate different embodiments of the present invention. 
[0012] Fig. 11 provides a graphical illustration of one embodiment of a rule tree 
for use by the software program of Figs. 4-5. 

Detailed Description 

[0013] The present disclosure relates to capacity management systems, such as 
can be used in an inter-office facility or a central office (hereinafter inter-office 
facility, or "IOF"). It is understood, however, that the following disclosure provides 



3 



Attorney Docket No.: 28787.70 



many different embodiments, or examples, for implementing different features of the 
invention. Specific examples of equipment, connections, and arrangements are 
described below to simplify the present disclosure. These are, of course, merely 
examples and aire not intended to limit the invention from that described in the 
claims. 

[0014] The following disclosure is divided into three different sections. First of all, 
an exemplary network and system is provided. The exemplary network identifies two 
telecommunication networks that may benefit from the present invention, and the 
exemplary system provides an example of a system for providing a graphical user 
interface for monitoring a specific node of either or both of the networks. Secondly, 
an exemplary software routine is discussed for implementing one embodiment of the 
graphical user interface. Thirdly, a plurality of screen shots are provided for 
illustrating the graphical user interface. 

Exemplary Network and System 

[0015] Referring to Fig. 1, the reference numerals 10 and 12 designate, in general, 
two simplified networks. The networks 10, 12 include a plurality of nodes 14 and a 
plurality of links 16. A node is a point of connection in a network, and can be of any 
size. For example, an IOF is a node of a telecommunications network. Likewise, the 
IOF may include many different pieces of equipment (e.g., switches), each of which 
may also be considered a node of the network. 

[0016] In the illustration of Fig. 1, some of the nodes exist in both networks 10, 12, 
and are therefore considered hubs. In the present example, each node includes a 
plurality of terminations where a service enters or exits the network 10, 12. In 
continuance of the example, the nodes 14 are IOF's and the links 16 are various types 
of trunks. 

[0017] Referring also to Fig. 2, a monitoring system 20 may be connected to one or 
more nodes of the networks 10, 12 for monitoring one or more pieces of equipment of 
the nodes. In one embodiment, the monitoring system 20 includes a personal 
computer 21 with a graphics display 22, a control unit 24, and user inputs 26 such as 
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a keyboard and pointer device. The computer 21 is connected through a log-on 
connection 30 to a file server 32, which also includes hardware equipment found in a 
typical server computer. The file server 32 is further connected to an inventory 
system 34, such as the TIRKS system discussed above. It is well known by those of 
ordinary skill in the art that various implementations can exist for the monitoring 
system 20. For example, in some implementations, the monitoring system 20 may 
include a larger, mainframe-type computer that is either locally or remotely 
accessible by a terminal or personal computer. In other implementations, the 
monitoring system 20 may include a series of computers. In still other 
implementations, the monitoring system may include or utilize a series of adjunct 
processors to one or more of the nodes 14. 

[0018] The monitoring system 20 can perform various software routines that can 
produce a series of graphical output images. The images are arranged in a unique 
way to illustrate the status of a particular node in the network 10. For example, the 
images can be used by network engineers to analyze one or more particular pieces of 
equipment at the node. The images can also identify exhaust conditions that may 
occur. The images are produced by a unique software program, discussed below, and 
may appear on the graphics display 22. 

[0019] Referring now to Fig. 3, for the sake of example, one node 14 of the 
network 10 or 12 may be an IOF 100, as illustrated. It is understood, however, that 
the illustrated IOF of Fig. 3 is simplified for the sake of clarity, and many different 
configurations are well known in the art. 

[0020] The IOF 100 includes many different pieces of equipment that a network 
engineer may desire to review. In the present example, the IOF includes one or more 
pieces of equipment described in Table 1, below. 
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Equipment 


Description 


D4 102 


A multiplexer/de-multiplexer unit for combining multiple digital 
lines (e.g., DSOs) 104 into a digital trunk (e.g., DS1) 106; 


ORB 108 


An office repeater bay that receives and amplifies a DS1 signal 110; 


Ml-3 112 


A multiplexer/de-multiplexer unit for combining multiple DSls 114 
intoaDS3 116; 


MFT1 118 


A 2-wire metallic frame terminal for amplifying and/or balancing an 
analog or digital line 120; 


MFT2 122 


A 4- wire metallic frame terminal for amplifying and/or balancing an 
analog or digital line 124; 


SMAS 126 


A port for allowing access and/or test of a digital line 128; 


Switch 130 


A trunk-side switch. Examples include a tandem (TMD) or plain old 
telephone (POTS) system; 


DCS1-0 132 


A narrow band electronic cross-connect system that reconfigures a 
DS0 134; 


DCS3-1 136 


A wide band electronic cross-connect system that reconfigures a DS1 
1 38- 

AGO, 


DCS3-3 140 


A broad band electronic cross-connect system that reconfigures a 
DS3 142; 


ATM 144 


An asynchronous transfer mode switch for trunks 146; 


DSL 148 


A digital subscriber line splitter 148 for servicing a DSL line 150. 



Table 1 

[0021] In the present example, it is desired to allow a user such as a network 
engineer to monitor and review one or more of the pieces of equipment of the IOF 
100. 



Software Description 

[0022] Referring now to Fig. 4, a rule based capacity management computer 
program 200 can be used for creating reviews of various equipment in the IOF 100. 
The computer program 200 may be performed by a single component of the 
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monitoring system 20 of Fig. 2, or may have different aspects distributed throughout 
various processing platforms. In the present embodiment, the computer program 200 
is performed by the file server 32. 

[0023] The computer program 200 includes a presentation layer 202, a business 
layer 204, and a data layer 206. The presentation layer 202 provides, in the present 
embodiment, the graphical user interface ("GUI") to the user (e.g., the network 
engineer). The GUI allows the user to set specific parameters for specific reviews and 
forecasts, and also presents the data from the reviews and forecasts. The 
presentation layer 202 may have many different components, such as listed in Table 



2, below. 



Component 


Description 


Review Monitor 


A table screen that shows how many reviews a user has 
created. It retrieves this information from the server. It 
also provides a history of the reviews. 


User Preference 


This describes user preferences, such as a location and 
responsibility, color of charts, and so forth. 


D&C Chart 


A graph of demand vs. capacity for a particular location. 


Chart Properties 


This allows customization of the D&C Chart. 


Forecast and Pending 
Job 


This is a report that allows the user to enter a single 
event forecasted demand and/or a published forecast. 
Also, the user can enter pending jobs that are not yet 
input to the inventory system 208. 


Review Details 


This provides parameters defined for the review. It 
identifies a time frame (e.g., monthly), forecast vs. trend, 
warning levels, etc. 


Standard Configuration 
Selection 


This identifies standard equipment configurations for 
the equipment. This is used to help determine the best 
combination of equipment, since the equipment 
configuration is fairly complex. 


Local Office Profile 


This assists how the system automatically selects 
equipment for a specific office. 


Job Justification Story 


This is a word-processing document automatically 
created by the system for specific vendors, (e.g., RBOCs). 
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Component 


Description 


Rule Based Editor 


This allows the user (or an administrator) to edit rules. 
For example, if an equipment type changes to a new 
model, different rules (with different parameters) may 
apply. 



Table 2. 

[0024] The data layer 206 includes a database of the raw data for the reviews and 
forecasts. The raw data comes from an inventory control system 208, such as the 
TIRKS system discussed above, using conventional techniques. In addition, the data 
layer 206 includes the rules that have either been predefined or defined by the 
network engineer. The rules define such things as specific configurations of pieces of 
equipment, typical equipment performance parameters, equipment endurance 
estimations, and so forth. An exemplary group of rules is provided in Table 3, below. 

Rule 

D4s come in groups of eight. 

D4s can handle x amount of capacity. 

D4s last for 2 years. 

Each D4 is 7 feet tall. 

Table 3 

[0025] The business layer 204 serves as the engine between the presentation layer 
202 and the data layer 206. In the present embodiment, the business layer 204 can 
predict future capacity situations in one or more pieces of equipment being reviewed, 
and can predict exhaust conditions among the pieces of equipment. The business 
layer 204 may have many different components, such as listed in Table 4, below. 
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Component 


Description 


Review Database 


This accesses the inventory system 208 (TIRKS) 


Inference Engine 


This is an artificial intelligence engine that performs the 
analysis, including the material for the D&C chart. 


Job Justification Story 


This creates the job justification story of Table 2 from the 
data layer 206. 


Detect Equipment 
Exhaust 


This identifies equipment exhaust conditions, from the 
Inference Engine 


Generate D&C Chart 


This creates the D&C Chart of Table 2 from the data 
layer 206. j 


Select Standard 
Configuration 


This selects the appropriate standard configuration for 
the review. 


Distribution 


This distributes the results. For example, an email can be 
sent to the user responsive to predetermined "alarm" 
conditions. 



Table 4. 

[0026] Referring now to Fig. 5, the computer program 200 begins execution at step 
250, where the network engineer defines a review. The engineer can define the 
review by selecting one or more pieces of equipment, and various parameters for the 
equipment. The engineer can also used predefined rules, or modify rules as desired. 
[0027] At step 252, data relevant for the review is tracked. In the present 
embodiment, the data may be acquired by the TIRKS inventory system 208. The 
data is provided in a raw format. This data acquisition may occur over repeated 
intervals for a time span specified at step 250. 

[0028] At step 254, the data is analyzed. The analysis is based on the previously 
provided rules. For example, the data can be accumulated in a predetermined 
manner, such as is required by a job justification story. 

[0029] Referring also to Fig. 6, in one embodiment, the data can be analyzed using 
an inference engine 300 to perform certain forecasts. For example, a prediction that 
the system under review will "exhaust" at a certain point in the future can be made. 
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Execution of the inference engine 300 begins at step 302 where the data acquired at 
step 252 (Fig. 5) is loaded. This data represents actual equipment status. At step 
304, the rule base is searched for a match. If the equipment matches a rule, then 
execution proceeds to step 306 where the rule is "fired." A rule is fired by performing 
"consequences" of the rule. A consequence is an action or a conclusion that can be 
made from the particular piece of equipment. At step 308, the consequence is 
provided for further analysis or reporting. Upon completion of step 308, or upon a 
negative determination at step 304, execution returns to step 302 until all of the data 
has been parsed (determined at step 309). As a result, each piece of data that has a 
corresponding rule will be fired on. 

[0030] Referring again to Fig. 5, at step 256, the data is organized into a 
predetermined format and reported. The data may be reported as a job justification 
story, in an email notification, and/or in various graphs. Since, in some 
embodiments, the program 200 may perform over an extended period of time, the 
data reporting step 256 may be repeated throughout the period of time, in similar or 
different reporting formats. 

Exemplary Screen Shots 

[0031] The program 200 can also be described by showing several different images 
from the presentation layer 202. Since the images are dynamic and interactive, 
screen shots of the images will be further discussed. The screen shots relate to 
exemplary situations of a node in the network, such as the IOF of Fig. 3. It is 
understood that different portions of the screen shots can be combined in various 
manners to produce even more examples of the graphical user interface. 
[0032] Referring now to Fig. 7, a screen shot 350 illustrates one example of the 
user preference component of Table 2, above. The screen 350 includes a menu 352 
that allows a user to select one or more possible regions (or "engineering areas") for 
review. Once a region is selected, a window 354 lists all the IOF's for the engineering 
areas. The user can then transfer specific IOF's to a window 356 for further review. 
Specific technologies can be selected in a window 358 and a time period for review 
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can be determined in a window 360. Once the selections are made, an initial review 
can be automatically created with a button 362 to create a review for the selected 
offices and technologies. Further customization is possible by activating a button 
364. This allows the user to choose "Review Monitor" and "D & C Chart" 
components as well as selecting an engineering function of the user. 
[0033] Referring also to Fig. 8, one advanced option is to modify a local office 
profile with a screen 400. In the present example, the configuration of an office 
repeater bay for a particular IOF (e.g. IOF 100 of Fig. 3) is to be modified (e.g., ORB 
108). Each IOF can have different frame heights, and hold different quantities of 
equipment. As such, the user can change certain parameters of the equipment in the 
IOF. 

[0034] Referring also to Fig. 9, a standard configuration list 450 may be used to 
select a standard configuration for a specific IOF. In the present embodiment, the 
standard configurations are fixed and created by engineering boards and/or various 
equipment vendors. 

[0035] Referring to Figs. 10 and 11, a rule-base manager screen 500 allows the 
user to define rules for the rule based capacity management program 200. The 
screen 500 allows the user to embed or encode business logic, company guidelines, 
and equipment properties into the rules. 

[0036] The rules are organized in a tree structure 502. One part of the tree 
structure 502 is a rule set 504. The rule set 504 categorizes the different "areas" of 
rules, which identify where the rules will be applied and helps the inference engine 
300 (Fig. 6) to identify which rule set to apply when the need arises. In the example 
of Fig. 10, a standard configuration rule set requirement ("StdConfigReq-S8") is one 
group of rules for a specific IOF. Other examples of rule sets would include a group 
of rules directed to timing requirements, sizing requirements, and so forth. 
[0037] Another part of the tree structure 502 are rules 506. Each rule includes an 
antecedent 508 and a consequent 510. The antecedent 508 serves as a precondition 
for the rule, and the consequent 510 serves as a conclusion for the rule. In the 
example of Fig. 10, the rule office repeater bay ("ORB") has one antecedent basis of: 
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TechName is ORB. 

[0038] If this antecedent is met, the following three consequents are made: 

Required Feature == TechName; 

Required Feature = = FrameHeight; 

Required Feature = = EquipmentDetail. 
[0039] The consequents dictate a name, frame height, and equipment detail 
description for the ORB. 

[0040] By having the above described tree structure, a great deal of flexibility is 
provided to the rules. For example, if later on the user wants to change the rules for 
the ORB, the consequent or antecedent can be readily modified. As a result, changes 
to equipment, company guidelines, or other rule logic does not require the user to 
rebuild the entire rule based capacity management program 200. 
[0041] Referring now to Fig. 12, another way to create a review is with the review 
monitor component of Table 2, above. A screen shot 550 illustrates one example of 
the review monitor component. The screen 550 creates a review (e.g., review 
"CRLS12DCO-5E M&S ALL T") for a particular piece of equipment (e.g., "DC0") of 
an IOF (e.g., central office "CRLSCA12"). A window 552 allows the user to schedule 
the review and a window 554 allows the user to select a certain piece of equipment 
with a HECIG code. The HECIG code identifies a human equipment common 
interface (HECIG) value. All the HECIGs that were included are shown, and can be 
sorted by a function 556. 

[0042] A window 558 allows the user to modify the growth rate of the IOF, if 
certain conditions are known. For example, a population area served by the IOF can 
be under relatively rapid expansion. A window 560 can allow different growth rate 
computation methods. A notification window 562 can be used to activate email 
notification of the user when certain conditions are met. A forecast button 564 
causes a forecast and pending jobs window to appear, discussed below. 
[0043] Referring to Fig. 13, a forecast and pending job screen 600 is used to 
illustrate different forecasts and jobs that make up a review. The screen 600 can be 
divided into two different sections: a forecast section 602 and a pending jobs section 
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604. The forecast section 602 indicates the status of a job (e.g., whether the current 
job is being used), the HECIG code of the exact equipment type, date and quantity for 
the forecast, and a description of what is causing the demand for forecast. The user 
(acting as the "owner") may create a forecast, may "insert" it in the review list, and 
may "include" or use the forecast in the review. The pending jobs section 604 
identifies various equipment modifications that are being performed. 
[0044] Referring now to Fig. 14, one type of forecast is a D&C chart, as discussed 
in Table 2, above. A screen shot 650 illustrates one example of a D&C chart. In 
continuance with the present example, the D&C chart 650 analyses an office repeater 
bay ("ORB"). A vertical axis 652 identifies a bit rate level (e.g., DS1) for the ORB, 
and a horizontal axis 654 identifies time. A curve 656 identifies maximum capacity 
for the ORB. As can be seen, the maximum capacity has been increased at several 
times during the previous months, due to various enhancements to the ORB. 
[0045] A curve 658 identifies working or consumed capacity of the ORB up until 
the time of the last review. In the present case, the consumed capacity 658 has 
always been below the maximum 656. A curve 660 identifies a projected trend for the 
consumed capacity 658. As can be seen, the projected trend 660 intersects the 
maximum capacity 656 at a point 662. In the present embodiment, the point 662 
identifies a date of 9/2002. This identifies to the user that an exhaust condition will 
probably occur at that date. The user may then respond appropriately, such as by 
increasing the maximum capacity for the ORB. The user may have requested email 
notification at a predetermined time before the point 662 (such as through the 
window 562 of Fig. 12). Since the review is performed for a period of time, more data 
will become available for analysis and a more accurate intersection point can be 
determined. 

Conclusion 

[0046] Thus, there is disclosed a system and method for monitoring and analyzing 
one or more pieces of telecommunication network equipment via a rule based system. 
In some embodiments, the system and method allow a user to quickly determine the 
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status of the equipment. The system may be interactive, and can quickly provide 
specific information without providing superfluous or unnecessary information to the 
user. In addition, implementations of the various embodiments described above can 
be performed very quickly, as compared to conventional techniques, such as running 
a TIRKS online report facility. 

[0047] While the invention has been particularly shown and described with 
reference to the preferred embodiment thereof, it will be understood by those skilled 
in the art that various changes in form and detail may be made therein without 
departing form the spirit and scope of the invention. 
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